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This document describes the communication architecture for the Power, Avionics and 
Software (PAS) 1.0 subsystem for the Advanced Extravehicular Mobility Unit (AEMU). 

The following systems are described in detail: Caution Warning and Control System, 

Informatics, Storage, Video, Audio, Communication, and Monitoring Test and Validation. 

This document also provides some background as well as the purpose and goals of the PAS 
subsystem being developed at Glenn Research Center (GRC). 
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I. Introduction 

The current Extravehicular Mobility Unit (EMU) suits (space suits) are still using technology from 
the 1970’s and 1980’s, particularly regarding the communications system. These systems work well, and 
there is always a reluctance to change space systems. There is nearly always the desire to be backwards 
compatible with proven systems, to reduce risk. Unfortunately, this backwards compatibility often occurs 
to the detriment of new technologies infusion, infusion that may actually reduce cost while dramatically 
improving capability. 

In order to infuse new technologies into the EMUs and prepare for future National Aeronautics and 
Space Administration (NASA) missions, NASA is currently developing an Advanced Extravehicular Mobility 
Unit (AEMU) a . This is being performed within the Advanced EVA Systems Development Project under the 
Advanced Exploration Systems (AES) Program. A key part of this development is the spacesuit Primary 
Life Support Subsystem (PLSS) technology unit for long-duration microgravity or planetary missions and 
vacuum or low-pressure environments. NASA GRC’s role is to develop the PAS subsystem. 

The PAS subsystem being developed at GRC supports the AEMU program at NASA’s Johnson Space 
Center (JSC). GRC’s role is to develop a prototype suit avionics subsystem and to research new technologies 
for the AEMU. The results will be used to refine requirements for the AEMU as well as to potentially 
integrate new technologies into the AEMU. 

* william, d.ivancic@nasa.gov 

t obed.s.sands@nasa.gov 

$ casey .j .bakula@nasa.gov 

§ daniel.r.oldham@nasa.gov 
^ ted. wright@nasa.gov 
II martin.a.bradish@nasa.gov 

**joseph. m.klebau@nasa.gov 

Copyright © 2014 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free 
license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the 
copyright owner. 

a A spacesuit that provides environmental protection, mobility, life support, and communications for astronauts performing 
an Extravehicular Activity (EVA) 
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II. Terminology 

To aid in discussion within this document it is useful to develop and define some terminology specific to 
our concepts of operations. 

Caution and Warning Events 

Our preferred caution and warning definitions are below. We prefer these to past definitions as they 
align with industry practices, such as terminology used in industrial plants and power plants. These 
definitions were altered in the Intersystem Communications Section in order to maintain consistency 
with terminology currently in use on the International Space Station (ISS) and previously used on 
Space Transportation System (STS) a.k.a. Shuttle. 

Alert Single Tone for minor events such as “Text Message Received” or when a suits operational 
configuration has changed. 

Caution Take notice, but don’t take action (usually flashing lights in the power plant). 

Warning Take Action Now. (These take precedence over Cautions). 

Data Types 

There are four basic data types listed below. Note, there are no command types or response types. 
Rather, we use events and telemetry. The interaction between subsystems is based entirely on a 
publish/subscribe concept that greatly simplifies code and reduces the amount of state that one needs 
to maintain. 1 

Application Specific (e.g., file transfer) 

Event - a message type indicating change of state that may require some action. Change of state 
includes items such as caution and warning signals, audio push button position changes, and call 
group selections. 

Streaming - real-time streaming applications such as audio and video 
Telemetry - system and subsystem status, configuration and measurements 

Call Group (i.e. Voice Loop) A group of voice reception devices that all listen on a common “channel”. 
For Voice- Over-IP (VOIP), the channel may be a multicast address and port. For simple Radio 
Frequency (RF) communications, that channel may be a particular frequency and time slot or spreading 
code. For illustration purposes, assume we have three AEMUs. Then, some examples of call groups 
for AEMU may be: 

• All three AEMUs 

• A single AEMU to Home and Mission Control 

• All three AEMUs, plus Home and Mission Control 

• Home and Mission Control 

Home Home is where the crew members return to after their EVA (e.g. ISS, Habitat, Base Camp, Tier-1 
Relay in the Network Diagram - Figure 4) 

Multi-Homed Network A node connected to two or more Wide Area Network (WAN) networks such that 
data has multiple potential paths in which it can flow to it’s final destination. For example the AEMU 
the communication system utilizes two separate radio networks and is thus multi-homed. 

Telemetry Often telemetry refers to ALL data coming from a spacecraft to the ground. For the AEMU, 
telemetry is just system and subsystem and assembly status, configuration and performance measure- 
ment data (e.g. suit internal pressure, suit internal temperature, power supply voltage, power supply 
current, radio transmission rate). All other data flows such as file transfers, and streaming video and 
audio are considered data flow and not telemetry. 
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Figure 1. Power, Avionics and Control Software Critical Systems 


III. Communication Architecture Design Philosophy 

The goal is to develop a flexible, extensible, testable, and cost effective architecture. The design is not 
just for use on the ISS or Orion, but for future planetary exploration science missions’ terrestrial sorties as 
well. There is also a great desire to be able to readily infuse new technology. 

PAS Assemblies have been developed, for the most part, independently. This was done for a number of 
reasons. First and foremost, Caution, Warning and Control System (CWCS) is a critical system that is being 
developed with a direct path to flight in mind. Thus, there is a desire to keep both the hardware and software 
as simple and reliable as possible while maintaining power and mass requirements. The audio processing and 
communication assemblies both have significant research elements. Allowing these assemblies to be developed 
independently enables these research elements to to be developed on parallel paths. The informatics system 
is highly desirable for AEMU sorties involving scientific research and terrestrial exploration. As such, it is 
considered a long-term development. 

Currently, each of the subsystems has its own processing unit. A future AEMU would likely have only 
two or three processors. The CWCS would likely maintain its own processor while the rest of the systems 
might share one. The communications and audio processing system may be combined having a separate 
processing unit. Informatics may have its own high-end processor and software as this unit is likely to be 
deployed last and updated often. This should not be a problem as Informatics is a “low-critical subsystem” 
2 . 

NASA’s current mission and budget profile drives the AEMU development to occur in a phased, evolu- 
tionary manner. One could anticipate that the CWCS, the audio, and the communications assemblies would 
be developed prior to informatics. This is particularly true since informatics provides its greatest return on 
investment for exploration sorties rather than EVA maneuvers around International Space Station or the 
Orion spacecraft. 

Due to limited resources (funds, people, and time), existing software technologies and techniques have 
been adopted such as using Google Protocol Buffers for telemetry, ZeroMQ® for messaging, and Wireshark® 
for monitoring activity across the Gigabit Ethernet (GigE) and WAN busses. 

There is also a great desire to learn from other’s experience. For example: the AEMU sortie operations are 
very similar to soldier operations as are many of the requirement and features. Both the army operations and 
the AEMU need separate call groups and multi- homed radio systems. The Soldier Radio Waveform project 
already has these capabilities. 2 The AEMU is also quite similar to Intelligent Transportation Services (ITS) 3 
vehicles with some systems being critical for safety of life and others being desired features. In many ways, 
ITS has more stringent requirements as security is a major concern. 

IV. Switches and Controls 

On the current EVA suits, the Display and Control Module (DCM) is where the EVA crewmember 
interacts with the PLSS. It contains displays and controls for the operation of the EMU and is attached to 
the front of the upper torso of the EMU . In order to read the displays at this location, the crewmember uses 
mirrors (attached to the arms of the EMU ) to reflect and read the information, which is written backward 
on the front of the suit. Sensor readings are provided to the crew and read on the top of the DCM on the 
Liquid Crystal Display (LCD) 4 - see figure 1. 

For the prototype AEMU, external controls such as switches and knobs are associated with individual 
assemblies. For example, the Push- To- Talk (PTT) and the volume control switch are associated with the 
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Figure 2. Power, Avionics and Control Software Critical Systems 


audio assembly. The call group knob (rotary switch), similar to that shown for Temperature control in 
figure 2, is associated with the communication assembly. In this instance, there are no commands either 
from other subsystems or external to the EMU to set the volume. It is performed by the audio assembly via 
the volume switch. However, there is a desire to display the volume settings. As such, a telemetry message 
containing volume information is periodically published by the audio assembly making it available to other 
subsystems or remote systems that desire the information. In a similar manner, the Communication system 
creates a telemetry message indicating the current call group setting (knob position). 

V. Telemetry 

Our desire is to develop a flexible telemetry format that does not required predefined large fixed-field 
data structures to be sent with each transmission. As such, we send only the relevant telemetry that two 
subsystems need to communicate. 

We investigated fixed ID/Data pairs such that each piece of telemetry is identified by a Flag indicating 
if the next field value is an ID or data. The ID value would indicate what the data represents (e.g. voltage, 
pressure, Bit-error-rate, etc, ...). The data value would represent the value corresponding to the ID (e.g., 
a Boolean value, Integer value, etc...). Upon further investigation, we decided to utilize Google Protocol 
Buffers (GPB) (or simply “protocol buffers”) 4 5 because it is a standardized format similar to what we were 
developing, and because it generates source code for the protocol encoding and decoding tasks. The telemetry 
format is shown in figure 3. Protocol buffers can be run over User Datagram Protocol (UDP) if so desired, 
but currently all messaging is implemented using ZeroMQ (Transmission Control Protocol (TCP) transport 
mode) for ease of development in our prototype subsystem - see section VIII. Protocol Buffers uses a key /value 
pair for each entry. Many of these key /value pairs utilize Variants , a variable length method of serializing 
integers using as little as one byte. This method allows for very efficient bits-on-the-wire encoding. In our 
deployment, the only required key/value pairs are Timestamp , Sender (e.g, CWCS, Informatics, Audio, 
COMM) and Type. All other key/value pairs are optional (depending on the required Type field), enabling 
great flexibility. 

A. Bits on the Wire 

In addition to the protocol buffer payload, the packet wire format contains zero to three null (0x00) padding 
bytes appended to the end to make the total ZeroMQ data size a multiple of 32 bits. This is needed 
to preserve compatibility with older ARM microprocessors that do not have native instructions for byte 
alignment. The protocol buffer payload is prefixed by a 16 bit field that stores the length of the payload in 
bytes. A 16 bit Cyclical Redundancy Check (CRC) is computed over the combined length, payload and pad 
bytes and is added before the length field. The CRC and length are stored in network byte order. Thus we 
have: 

1. A 2 byte CRC calculated over of the rest of the packet (network byte order) 

2. 2 bytes which are the length of the encoded protocol buffer (network byte order) 

3. A variable length encoded protocol buffer payload 
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Figure 3. Protocol Buffer Telemetry Format 


4. 0 to 3 pad bytes (0x00) to make the total packet length a multiple of 4 

B. Google Protocol Buffers 

Use of GPB greatly simplifies coding as all header information and associated data structure are automat- 
ically generated from the GPB “.proto” file. Protocol buffers are now Google’s lingua franca for data at 
time of writing, there are 48,162 different message types defined in the Google code tree across 12,183 .proto 
files. They’re used both in Remote Procedure Call (RPC) systems and for persistent storage of data in a 
variety of storage systems. 

Since protocol buffers are so widely used, additional tools have been created by third party developers. 
PAS 1.0 uses the following protocol buffer related software: 

• nanobp is a plain C language implementation of Google’s Protocol Buffers data format and is used 
instead of the C++ language default implementation. It is targeted at 32 bit microcontrollers, but is 
also fit for other embedded systems with tight (2-10 kB Read Only Memory (ROM), <1 kB Random 
Access Memory (RAM) memory constraints. 5 6 

• protobuf-wireshark is an auto-generated Wireshark dissector plugins for GPB messages. 7, 5 

C. Messages 

Since the AEMU PAS 1.0-subsystem is a prototype used to develop the necessary requirements and raise 
the technology readiness level closer to a flight implementation, we concentrated on developing the required 
messages and human readable code and were not overly concerned with the efficiency of bits-on-the-wire. 
To speed development, PAS 1.0 uses the ZeroMQ 8 messaging library to avoid the complications of writing 
reliable publish/subscribe networking code. We feel it is far more valuable in this prototype effort to con- 
centrate on the Messages (what needs to be communicated between subsystems and AEMUs) rather than 
the Messaging implementation. 

A Publish/Subscribe network architecture is a best practice for reliable information exchange between 
loosely coupled networked assemblies, such as the AEMU. While it is possible to create a simple system 
based on UDP broadcasts, past experience has shown that making it reliable and fixing all the corner cases 
can become complicated. Building distributed software and getting code talking to code can be difficult and 
expensive. The open source ZeroMQ socket library makes coding a basic publish/subscribe system trivially 
easy, requiring about a dozen lines of code. ZeroMQ is a library that is linked to code, so unlike most other 
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” middleware” solutions, it does not require a separate daemon process or broker software. It was originally 
developed for high frequency trading applications on Wall Street where efficiency is paramount. 

D. Software 

In the PAS 1.0 interfacing effort, there is a great desire to develop assembly software for reuse. Using Google 
Protocol Buffers and ZeroMQ enable this. With protocol buffers one can easily add key/value pairs without 
affecting existing code. Using ZeroMQ one can easily switch transport mechanisms as it can use different 
protocols depending on the peers location (TCP, Pragmatic General Multicast (PGM) multicast, Interpro- 
cess Communication (IPC), inproc shared memory), 9 which is extremely importantly for our code reuse. 
One can easily switch from an Internet Protocol (IP) routing to IPC or in process shared memory. Thus, if 
the bus structure changes from GigE to Peripheral Component Interconnect (PCI) bus or some other bus, 
one simply needs to change the transport type in ZeroMQ code and not much else (e.g., in the italicized line 
below, tcp become PGM for multicast and IPC for interprocess communication). 

sub Sockets, connect ( tcp://localhost:%cT %pubPort ) 

Software was developed in a manner that allows each assembly to draw upon a common library of 
messages This enables an assembly’s software to remain intact even if the bus architecture changes. 

Originally we were going to implement a common set of Application Program Interface (API)s. However 
using ZeroMQ and protocol buffers, the messaging was so simple, that there was no need for actual API 
development. We were able to go from message construct development to integration, test and validation in 
approximately 2 months with communication between four unique assemblies. 

VI. AEMU Communication Architecture 

Figure 4 shows the AEMU communication architecture block diagram. The AEMU has three networks.: 
The local area networks, the low-rate, critical RF communication network, and a high-rate, wide-band RF 
communication network. Figure 4 also shows the basic addressing scheme selected for both the GigE and 
WANs i.e., the radio networks. All networks in this architecture are addressable via Internet Protocol version 
4 (IPv4) and Internet Protocol version 6 (IPv6) addressing. The preferred choice is to use IPv6 addressing 
as all future technology developments related to Internet protocols are likely to occur using IPv6 address 
space. 

A. Internal Bus 

All the assemblies are connected via a GigE bus. GigE was selected to handle large amounts of data generated 
from the video assembly as well as ease of subsystem integration. This ensures sufficient available bandwidth 
across the bus for all assemblies, but more specifically, to handle multiple streams of high definition video. 
Furthermore, software and drivers are readily available in most operating system to easily move data across 
an Ethernet bus. No custom driver software needs to be developed, saving time, energy and money. 

For the local area network the onboard network, each subsystem has an address unique to the local 
network. Although unique to the local network, this address space is identical for each AEMU. All routes 
off the suit send information to the communication subsystem. The communication subsystem is the default 
route to external systems. Likewise, all information coming from external sources would be received by the 
communications subsystem and routed to the appropriate subsystem. 

B. Radio Networks 

There are two separate RF networks: a low-rate UHF radio network and a high-rate, wide-band radio 
network. Each radio network has its own address space and is on its own subnet. The critical communication 
RF network is a low-rate network over a UHF radio system. Information transferred over the system includes 
voice and critical telemetry. The wide-band communication radio network may carry voice, critical telemetry, 
video, and noncritical data such as scientific data taken during a terrestrial sortie. There are many possible 
ways to utilize these networks. The first is to always have audio communication and critical telemetry flow 
over the UHF radio and all other data to flow over the wide-band RF system. This, however, precludes the 
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Figure 4. Power, Avionics and Control Communication Architecture 


use of the wide-band system for critical communications. As such, in the event that the UHF system fails, 
one would be unable to take advantage of the wide-band system even if it is working. A second possibility 
would be to have all communication flow over the wide-band system with the critical system in standby 
and only active when a wide-band first system fails. However, it is been shown that the wide-band system 
conductivity will fail often so this is probably not a valid operating mode . 10 The third possibility and 
probably the most reliable would be to have both radios operating simultaneously with voice and critical 
telemetry flowing over the UHF system and all other communications flowing over the wide-band system 
with an option to enable critical communications to flow over the wide-band system if the UHF radio system 
were to fail. This may introduce undesired complexity. A detailed study of such an architecture would have 
to be completed to prove or disprove this complexity assertion. 

The UHF radio network has a much further range than the wide-band radio network. As currently 
envisioned, all radios in this network are expected to be within range of each other, that is, there is no 
expectation of using these radio nodes in a multi-hopped Mobile Ad Hoc Network (MANET) network. 
However, using a multi-hopped MANET network over the UHF radios could greatly extend the range of 
critical communications - perhaps with little additional complexity since MANET routing is already designed 
into the communication system for the wide-band network. 

The range of wide-band radios is limited. In order to maintain connectivity between wide-band radio 
nodes and HOME, each node is designed as a MANET forwarding agent to enable a multi- hoped com- 
munication and extend the overall range of the wide-band network. It is certainly possible and perhaps 
advantageous to actually combine the UHF and wide-band radio networks into a single MANET network or 
to have two separate MANET networks: the critical radio network and the wide-band radio network. 

It is important to note that although the system described here is for the AEMU, the multi- homed 
radio network most certainly could be used by other systems such as a group of cooperative robots or rovers. 
Developing a single multi-use communication system would allow space agencies to reduce costs and improve 
reliability of the overall communication system as well as distribute costs across various groups such as the 
robotics missions and the human exploration missions. 
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C. Discovery and Registration 

In order to simplify network configurations and improve reliability by avoiding mis-configurations, it is highly 
desirable to have some form of automated system and service discovery and registration 11 . 12 Furthermore, it 
is important that no single point of failure exists in the system. Therefore, all services should be designed to 
operate without a centralized server. This is very similar to the desired operation in a military edge network. 
In fact, many of the techniques used in military edge networks should be applicable, yet simpler to apply, 
since network security issues are quite limited in a space-base network versus a terrestrial military network. 
Since space networks, particularly the AEMU communication networks, are relatively small, scaling is a non- 
issue, which makes deployments much simpler than for large terrestrial networks. For example, techniques 
similar to distributed host tables are reasonable for networks of tens of nodes but may be unreasonable for 
millions of nodes. 

A registration process consists of mapping services on a system such as an AEMU, robot, rover or HOME 
with the system ID; mapping the system ID to network addresses; and distributing this mapping. For a 
multi- homed system, a particular service may be reachable via multiple paths. The discovery process consists 
of locating systems and determining what services that system offers and/or desires. 

There are many server-less technologies and services being developed. Many are directed at challenged 
networks such as communication within a remote village, or disaster relief and recovery where existing 
infrastructure does not or no longer exists . 13 Development of server-less applications is also taking place 
for security reasons as your data and messages are never stored on any server, so they are safe from data 
breaches and prying eyes. 14 This is of great concern for some corporate network as well as individuals 
per recent public revelations regarding government activities 15 and data mining activities of major Internet 
service providers such as Facebook®, Google®, Yahoo® and others. Regardless of why these technologies 
are being developed, they are quite applicable to space-based networks. 

D. Naming and Addressing 

In order to facilitate discovery and registration, a well thought out naming and addressing scheme is required. 
Naming is currently a major research topic in the Internet Research Task Force (IRTF), Information Cen- 
tric Networking Research Group (ICNRG). Distributing and manipulating named information is a major 
application in the Internet today. Furthermore, Point-to-Point (P2P) and Content Delivery Network (CDN) 
are promoting a communication model of accessing data by name, regardless of location. Our network of 
AEMUs and rovers is an example of a P2P network. A good example of naming and addressing is presented 
in Day’s book, “Patterns in Network Architecture. 16 ” A phone number use to be an actual physical address 
attached to an endpoint. Each portion of the phone number indicated a region of the country or city. Today, 
phone number is simply a phone service identifier indicating the identity of a particular endpoint. When 
one powers on their cell phone, it registers the phone number as a service request which gets mapped to a 
particular address. That address may be a 4G cellular network address at one point in time and then IP 
address when the phone is attached to a Wi-Fi network. Thus, the phone number is no longer a physical 
address, but rather a service ID associated with a unique endpoint. 

Since each AEMU in the architecture shown in figure 4 has identical internal addressing, in order to 
uniquely identify an AEMU, each AEMU has to have a unique name. As of September 2013 for PAS-1.0, 
that unique name was the suit identification (i.e suit ID). However, since different crewmembers can use the 
same suit, it may be more appropriate to be an name uniquely associated with the crewmember - similar to 
how a smart card embedded with a digital security certificate is associated with a individual. Regardless, 
all applications and services (e.g. voice communications, file transfers, video, medical telemetry) provided 
by any AEMU should be associated with the unique name, not any point-of-attachment addresses. 16 The 
application to point-of-attachment mapping occurs as part of the discovery and registration process and 
reregistration process where reregistration occurs when one perceives change in network attachment. This 
facilitates auto configuration as well as mobility (i.e. continuous communication when moving across various 
subnetworks). 


VII. Subsystems 

There are four major subsystems being developed under PAS 1.0. They are: (a) the Caution Warning 
and Control System, (b) Informatics, (c) Communications, and (d) Audio. Also included is a Measurement, 
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Test and Validation (MTV). For PAS 1.0, the Video system and the Storage system will not be developed. 
These systems are being considered for future implementation. Each of the systems will be described in 
detail in the following sections. Note that , for PAS 1.0, much the communication architecture described 
above has not been implemented for this phase of the development effort. 

A. Caution Warning and Control and Power Management and Distribution 

1. Description 

The Caution, Warning and Control (CWC) includes the subassemblies for the PLSS control. The CWC 
Assembly monitors the data channels coming to it from the sensors within the PLSS, and detects out-of- 
range and anomalous readings. It then reports these caution and warning items to the crewmember as text 
on a small display and as tones through the same speakers in the helmet as those associated with the inbound 
voice audio i.e., there is only one set of speakers in PAS subsystem and all caution and warning tones run 
through the audio process subassembly. 

The CWC Assembly is assigned a Criticality- IS designation, since it is monitoring a life-critical hardware 
item and is critical for warning the crew of depleted life support resources or safety hazards due to malfunction 
of the life support system. Any software on the CWC Assembly would be software Class- A as defined in 
NPR 7150. 2A. 17 

The Power, Management and Distribution (PM A ^subsystem distributes power to the avionics, PLSS, 
and tools of the EVA system. It includes the battery and recharging interfaces, as well as battery health 
monitoring. It is currently envisioned that most powered devices will derive power from a single suit power 
source, as opposed to separate batteries for separate devices. 

Since the PM AD Assembly provides power to safety critical systems, the hardware and avionics are 
considered Criticality- 1, and any software in the PM AD Assembly is Class- A. 

The CWC subsystem monitors and controls the Power Management and Distribution subsystem. For con- 
trol purposes PMAD is considered part of the CWCS. The allocation of critical systems is shown in Figure 6. 


2. Implementation 

The CWCS is the primary focus of the development effort regarding form, fit and function at a pre-Pre- 
liminary Design Review (PDR) level of maturity for PAS 1.0. 18 The CWCS is designed to fit in a box 
approximately 10.25 inches (in.) long x 6.25 in. deep x 3.8 in. high, as shown in Figure 5. 

When fully implemented, the CWCS will provide the following functions: 

• Monitor the status of PLSS life-support functions (e.g. consumables and component status) for display 
to the EVA crewmember 

• Provide PLSS fault detection to alert the crewmember of off-nominal conditions and perform corrective 
actions 

• Electronically control the following PLSS components: 

— the Suit Water Membrane Evaporator (SWME), which provides heat exchange for the thermal 
control loop by vaporizing water (H20) across a water membrane wall 

— a fan which circulates gases through the oxygen ventilation loop 

— the Temperature Control Valve (TCV), which is a diverter valve that adjusts the amount of 
cooling flow to the crewmember, either manually by the crewmember or automatically via a 
control algorithm 

— the Rapid Cycle Amine (RCA) swing-bed, which provides carbon dioxide (C02) scrubbing and 
humidity removal of the ventilation loop 

— a pump which circulates H20 through the liquid cooling loop to provide crewmember cooling 

• Monitor the Primary Oxygen Regulator (POR), which provides suit pressure regulation at multiple 
pressure set points of oxygen (02) delivered from the primary 02 system 

• Monitor the Secondary Oxygen Regulator (SOR), which provides suit pressure regulation at a single 
pressure set point of 02 delivered from the secondary 02 system 
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Figure 5. PAS CWCS Packaging Illustration 


3. Operations 

In an operational setting, the CWCS will not receive commands from off suit or from any other EVA 
subsystems. It only sends asynchronous Events (e.g., set point changes) or periodic Telemetry (e.g., health 
and status information). For the development system, one may wish to send messages to the CWCS to 
configure the type of telemetry being sent and the frequency in which various telemetry messages are sent. 

One critical hardware item that belongs to CWCS is the Caution and Warning Acknowledgement switch 
(ACK). ACK is used to control caution and warning tones. The messages CWCS sends to Audio indicate 
cautions or warnings include data showing whether or not these have been acknowledged. A lookup table 
or some other mechanism will be used to determine how long an acknowledgement is valid. It may be that 
for emergency warnings, one may wish to clear the acknowledgement after some period and force the crew 
member to re- acknowledge cautions and particularly warnings. 

CWCS publishes Caution and Warning Report messages. These report message include a Caution or 
Warning time stamp, a Caution or Warning type, a flag indicating whether the message is a caution or 
warning, and a flag indicating whether this Caution or Warning has been acknowledged - see Section B, 
Messages. 

4- Research 

The CWCS is an engineering development prototype effort. Information obtained from this development 
effort will be documented for use in developing requirements for future AEMUs. In addition, the AEMU 
contractors may decide to utilize various internal architectures, and techniques demonstrated here. 

B. Audio Processing 

1. Description 

The Audio Subassembly provides for the handling and control of the audio signals retrieved from the inte- 
grated audio processing subassembly located in the helmet and delivers the audio to the communications 
subsystem or informatics. Likewise, the Audio Subsystem processes audio received from the communications 
subsystem and delivers that to the integrated audio processing subassembly. The Audio subsystem also is 
required to mix up to four separate inbound audio streams for the Communication subsystem along with 
caution and warning tones and deliver that to the integrated audio processor speaker subassembly. 

The Audio Subsystem interfaces to the Communications subsystem through a GigE bus that is separate 
from the subsystem GigE bus and delivers microphone array signals prepared to be processed by the Audio 
Subsystems. Audio data is also sent from the Communication assembly to this assembly to be delivered to 
the speakers. 
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Figure 6. Power, Avionics and Control Software Critical Systems 


2. Implementation 

Initial implementation was accomplished using an embedded processor development board using an Avnet 
Spartan-6/0MAP Co-Processing Development Kit for the outbound voice channel (voice off-suit) and a 
netbook computer to process the four inbound channels. The GStreamer open source software was used to 
encode and decode audio streams. 19 This was done simply to have a working audio system available for 
inter-subsystem message communication testing to test message passing between subsystems as there was 
approximately two months available from conception to integration testing. Four additional netbooks were 
used to emulate four external audio sources thereby providing four inbound channels. The operating systems 
on both the embedded processor board and the netbooks was Linux Ubuntu. This allowed ah software to 
be common between the embedded processor and the netbooks. Note, this is not the configuration for audio 
processing that would be deployed. It was done simply to enable testing of messaging (i.e. telemetry and 
events). Details of this implementation testing is available in the PAS Subsystem Interface Test Report. 20 

3. Operations 

There are three switches associated with the Audio system: (a) Mode, (b) Push-to-Talk, and (c) Volume. 
There is an additional switch owned by CWCS that directly affects the Audio system processing: the Caution 
and Warning Acknowledgement switch (ACK). 

Mode (MODE) - The MODE switch is set for either PTT, Voice Operated Switch (VOX) or Open Mi- 
crophone (Open-Mic). 

Push-to-Talk (PTT) - If the MODE is set to PTT and the PTT switch is not set, no voice data will 
how oh suit. If the MODE is set to PTT and the PTT switch is set, voice data should how to the 
appropriate call group (s) as selected by the Communication subsystem Call Group rotary switch. 
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Volume (VOLUME) - The Volume Switch increases or decreases the overall volume of the combined 
audio heard by the crew member. This is implemented to increase slowly while in the UP position and 
decrease slowly while in DOWN position. In PAS 1.0, individual in-bound channel volume is controlled 
via commands from Informatics. 

Caution and Warning Acknowledgement (ACK) - ACK is used to control caution and warning tones. 
CWCS sends messages to Audio indicating caution or warning and whether or not these have been 
acknowledged. This switch will silence those tones. If the caution or warning tones have not been 
acknowledge, Audio plays the tones according to information found in a lookup table. That information 
includes: enunciation, tone frequency, and tone repletion period (with zero meaning continuous). 

Audio modes include PTT and VOX, and OPEN MIC. You can effectively achieve a MUTE mode by 
selecting PTT mode on the mode switch and not pushing the PTT button. OPEN MIC is the default. If 
MODE is set to VOX, only audio that contains voice will flow off suit. In Open-Mic is selected, all audio 
is sent off suit even if nothing is being said (no voice activation). Thus, the receiving system will hear 
everything, including just breathing and background noise, assuming this is not filtered by some type of 
audio processing. 

Regarding voice generated on-suit, Audio will send Informatics an audio stream in Linear Pulse Code 
Modulation (LPCM) encoding format. Informatics can store this for archiving purposes or use it for voice 
recognition commanding and voice notes. Audio will be sent off-suit according to the position of the corre- 
sponding audio switches and the call group switch or some type of indicator. A possible call group is “Local 
Only” such that no transmission goes off suit. For safety reasons, this may not be desirable or one may want 
to be able to over-ride this remotely from HOME or Mission Control. 

Since all audio is being placed on the internal bus for the Informatics and Communication subsystem 
to pick up, both the MODE and PTT switches could belong to the Communication subsystem rather than 
Audio. This may actually simplify processing as no special telemetry messages indicating switch positions 
have need to be sent from Audio to COMM. However, the current approach is to keep these with Audio 
because giving the radio assembly a set of switches related to voice blurs the line between radio and Audio 
functionality. 

For PAS 1.0, the Audio subsystem will locally store all locally generated audio data for one sortie’s data 
(for PAS 1.0 the assumption shall be that one sortie is up to eight hours in length). In future AEMUs 
implemented with a separate Storage system, audio storage may occur in the storage subsystem rather than 

locally. 

It is possible that there is currently sufficient processing power within the Audio subsystem to perform 
voice commanding. However, that function is currently be delegated to Informatics. Thus, all voice is 
transmitted to Informatics regardless of any switch positions. This is necessary in order for Informatics to 
always hear and interpret voice commands as well as for taking audio notes. A good example of current voice 
recognition software is Dragon Dictation®. Dragon Dictation allows a soft switch and an audio command. 
To turn on voice commands one can use the GUI switch or say “Wake up” . To turn off voice commands or 
dictation one can also use the GUI switch or say “Go to sleep” . Informatics running similar software would 
need to receive all audio to process the “Wake Up” or “Go to Sleep” commands. 

4- Inputs 

For PAS 1.0, the Audio subsystem will obtain inbound channel gain settings for up to four channels from 
Informatics or the Monitor, Test and Validation system. 

In order to set the proper audio gains, the Audio subsystem needs static pressure measurements from 
the suit helmet. Those measurements come from CWCS. For PAS 1.0 these will be periodically transmitted 
and repeated at a rate sufficient to maintain steady state gain. 

For PAS 1.0, the caution and warning tones will be generated within the Audio subsystem along with 
associated aural annunciations. Notifications come from CWCS via messages sent across the GigE bus. One 
of four warning tone types (advisory /alert, caution/ warning and emergency) is associated with each warning 
type. The warning types are: 

Information - tones used to direct crew attention to messaging of an informational nature (i.e. buddy 
warnings and text messaging) 
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Status - tones used to identify failures during suit checkout (i.e. failed leak check) and other messages of a 
status nature 

Alert - tones used to identify successful progress during a suit checkout (i.e. start leak check & successful 
leak check) 

Warning - tones uses to identify serious system issues upon which a crew member needs to take immediate 
action (including faults during an EVA ) 

The following Caution or Warning examples are taken from the NASA GRC EVA PAS Subsystem Ar- 
chitecture Data Book: 

• Radiation High 

• Oxygen Low 

• C0 2 High 

• Water Low 

• Suit Pressure Out of Limit 

• Battery Low 

• Vent Fan 

• Thermal Pump 

• H 2 0 Heater 

• LCG Cooling Valve 

• Glove Heater 

5. Output 

The Audio subsystem will provide various health and status messages. Included in these messages will 
be switch settings and gain settings for each inbound channel and the local voice channel. Other health 
and status messages that may be useful are current and available storage, power consumption, or other 
measurable hardware related parameters. 

For PAS 1.0, detailed system configuration settings are assumed to be available from a configuration file. 
As stated earlier, the Audio subsystem will provide voice messages to Informatics for use in voice recogni- 
tion and audio notes. In future implementations, each message may be tagged with the following information: 
Time Stamp , Voice Activity Detection ( VAD ), Gain , MODE setting and PTT and might include a payload 
consisting of a nominal 10 ms of LPCM audio. These packets are transmitted as unicast UDP packets from 
Audio to Informatics. 

Outbound streaming voice data from Audio to Communication shall be unicast. Communication shall 
re-transmit to other external nodes according to route tables and call group settings. 

For our initial PAS 1.0 interface tests performed in the August of 2013, audio distribution was performed 
quite differently as described in the test report. 20 GStreamer 19 audio streams were sent between external 
systems (e.g. Home and other AEMUs) using notebooks to emulate external systems. All GStreamer packet 
were sent unicast and channel (source) separation was performed using a different port number for each 
source. 

6. Research 

To date, the main research activities have been directed at eliminating the communications helmet (a.k.a. 
“Snoopy cap”) while still maintaining acceptable speech quality. Research includes speech quality and 
intelligibility tests and determining audio processing, microphone array and placement options. For example: 
figure 7 shows microphone array on flexible polyimide circuit board. This is a prototype and the actual 
microphones would be much smaller. 

Research ongoing in Digital Signal Processing solutions for audio processing focusing on temporal/spatial 
processing includes: 

• Adaptive beamforming 

• Linear beamforming 

• Structure borne vibration suppression 
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Figure 7. Microphone Array on Flexible Polyimide Circuit Board 


• Echo cancellation 

Implementation and processing technologies being investigated and deployed include: 

• PGA, DSP processors 

• MEMS microphones, Electret microphones 

• Analog, digital array interfaces 

C. Communications 

The Communication Subsystem contains the baseband processing and formatting of the digitized data that 
is transmitted and received, including digitized voice. The Communication subsystem performs the routing 
of information on and off the AEMU as well as configuration control of the radios. 

The Communication Assembly is assigned a 2R Criticality, assuming that if the voice communications 
are lost during an EVA, the mission (the EVA ) would have to be terminated on that day. If communications 
could not be repaired, the mission would be seriously jeopardized. Software for the Communication assembly 
(and Navigation if included as an upgrade) is assumed to be Class- A based on requirements for similar 
manned systems, and as defined in NPR 7150.2. 

1. Radio 
Description 

Due to the often conflicting requirements of high data rates and reliable radio coverage, a dual-band 
radio architecture is proposed for AEMU suit systems. This radio would use a wide-band, high data rate RF 
interface with enough throughput to handle simultaneous voice, telemetry, and video flows, as well as a lower 
data rate RF interface that can carry mission essential voice and telemetry. The wide-band interface would 
be used amongst all radios while they are in range of each other, Since the range of wide-band networks is 
relatively short, the low-rate interface will be utilized when the wide-band interface fails. Non-essential data 
flows originating from the suit will be queued up locally on the suit and transmitted when the wide-band 
network is once again available. This concept allows for each of the two interfaces to be designed separately 
according to each set of requirements for both coverage and high data rates. 10 


Operations 

For PAS 1.0, neither a dual-band radio nor MANET routing were demonstrated. Rather, a single 
wide-band 802.11 radio broadcast network was utilized (i.e. all radios are within range). The radios were 
configured for “ad-hoc mode” rather than “infrastructure mode” so that there is no single point of failure 
(access point failure). 
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Operationally, there is nothing to do relative to the radios except turn them on or off. There will 
eventually be health and status data that will be placed into telemetry messages. 

One potential operational consideration is to have the wide-band radio shut down to save power when 
battery power falls below some threshold. This could be accomplished either via a specific command from 
the CWCS or by monitoring the CWCS telemetry power status and taking appropriate action. The later 
allows reduced software complexity in both the CWCS and Communication system while allowing both units 
to evolve independently. 

Research 

In the Fall of 2011, the NASA GRC participated in the Desert Research and Technology Studies Desert 
Research and Technology Studies (DRATS) field experiments held near Flagstaff, Arizona. A Dual-Band 
Radio Communication System was demonstrated during this outing. The EVA radio system was designed to 
transport both voice and telemetry data through a mobile ad hoc wireless network and employed a dual-band 
radio configuration. 10 Some key characteristics of this system include: 

• Dual-band radio configuration. One radio is used for high data rate communication and the other 
radio is used for contingencies to provide improved coverage and extended operational range. 

• Intelligent switching between wireless networks with two different capabilities. The switching algorithm 
utilized the expected transmission count for the wireless links in order to select the appropriate wireless 
network. 

• Self-healing network. Alternative data paths are determined either within the same network, or by 
transitioning to an alternative independent wireless network with different capabilities and character- 
istics. 

• Simultaneous data and voice communication. The wireless communication system uses Media Access 
Control (MAC) layer traffic control and open source Speex-based Voice over Internet Protocol (VoIP) 
technology. 

The significant research challenge lies in the implementation of this wireless interface on a hardware 
platform certified for operation beyond the Low-Earth Orbit (LEO) environment. Currently, a flight-grade 
chipset that implements a commercial Wireless Local Area Network (WLAN) interface does not exist. The 
questions that need to be answered regarding this include what will the costs be for the design and fabrication 
of an Application Specific Integrated Circuit (ASIC) chipset and which wireless interface standard will be 
most suitable for the wide variety of spacecraft proximity communications applications. 

Research is ongoing into development of a new lower data rate RF radio waveform to replace the current 
Space-to-Space EMU Radio Space-to-Space EMU Radio (SSER). 21 The current SSER waveform cannot 
support new technologies like packetized IP data and its telemetry format is fixed. The current SSER has 
heritage to the 1970’s and is designed for ease in integration with the 1553 Bus onboard the spacecraft. 
Research involves modernizing this waveform to ease integration with a routed packet network. Some of the 
issues that need to be addressed are the design of a MAC protocol that maintains the reliability of the SSCS 
and also meets the requirements for ad-hoc routing, supporting packetized IP, and increasing the robust- 
ness of the physical layer by considering things like short /long-term channel estimation feedback, adaptive 
modulation and coding, and dynamic spectrum access, which are challenging problems in a decentralized 
radio network. Another desirable feature of this interface is the ability to re-configure the waveform on orbit, 
so there are also open research issues regarding how to build a flight grade software-defined radio with a 
low enough Size, Weight and Power (SWaP) footprint that it may be used on the suit. This will require 
hardware components with capabilities beyond those used in the software-defined radios developed for the 
Mars program. 

2. Routing 
Description 

For general AEMU development, routing should be able to accommodate the generic network scenario 
shown in figure 4 and described in DRATS field experiments report. 10 In general, one should be able to 
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accommodate a multi-homed, dual-band radio with policy-base routing such that only critical voice and 
telemetry flows over the Ultra High Frequency (UHF) reliable radio network whereas high-rate science data 
and video flow over the high-rate radio network. Furthermore, the radios should allow for multi-hop routing 
(routing through multiple suits). Much of this has already been demonstrated and new technologies and 
techniques are being produced at a rapid pace. 22, 3 

Operations 

For PAS 1.0, the IP addressing scheme is provided in figure 4. IPv6 addresses should be used wherever 
possible as all new commercial Internet technology is expected to utilize IPv6 addressing. This is particularly 
true for mobile ad hoc networks. 

There are currently no plans to implement Delay /Disruption/Disconnection Tolerant Networking (DTN) 
on the AEMU, and there is currently no concept of operations indicating a need within the AEMU. DTN from 
HOME to wherever could be considered, but there is no demonstrable need for multi-hop store, carry and 
forward regarding any AEMU scenarios - particularly if no terrestrial EVA s are expected in the foreseeable 
future. 

All IP packets are forwarded on-suit or off-suit according to the forwarding (route) tables. Application 
that utilize IP addressing should operate without any issues assuming sufficient bandwidth. 

There will be a handful of pre-defined Call Groups (a.k.a. voice loops) that the crew members can switch 
between during a sortie. Communication will translate these loops into appropriate addresses (possibly IP 
addresses if IP is used on the radio links) and transmit the packets accordingly. 13 Those voice loops will be 
defined by mission control and can be modified at any time. Currently, the plan is to have Call Groups 
defined in a configuration file. Where the file resided is To Be Determined (TBD). For PAS 1.0, that file 
will be stored in the Communication system. 

Potential call groups include: 

• Local ONLY - No voice leaves the suit. This is for voice commands and audio message stamping of 
experimental data. 

• Broadcast - All parties involved including other AEMU’s HOME, and mission control 

• Proximity Crew Only (voice between AEMU crew only... However, this may not be a permitted mode 
of operations.) 

• Mission Ops Only (voice between the crew member and mission ops, which excludes other AEMU crew) 

Audio sends its outbound streaming voice data to Communication via unicast IP packets. Communication 
shall re-transmit to other external nodes according to route tables and call group settings. 

Caution and warning report messages from CWCS shall be published (transmitted) off-suit to the CWCS 
caution and warning subscribers. These message should come directly from CWCS . The report message 
will include a Caution or Warning time stamp, a Caution or Warning type, a flag to discriminate between 
caution or warning, and a flag indicating if this Caution or Warning has been acknowledged. 

Research 

Technology related to multi-home radios and routing is likely to move ahead within the commercial arena 
at a far greater pace and with far greater investment than NASA can provide. Such technology already 
exists in smartphones and is likely to become standard in vehicle-to-vehicle and vehicle-to-infrastructure 
communication. Thus, no new research is currently planned related to multi- home dual-band radio wireless 
and network interface standards. 

Time Synchronization 

In PAS 1.0, the Communication subsystem is responsible for supporting time synchronization with the 
other subsystems. The current implementation is running Network Time Protocol (NTP) 23 on all subsystems. 
As timing requirements do not call for high precision, NTP should be sufficient. 

b There is discussion of leveraging other radio systems such as the Joint Tactical Radio System (JTRS) Soldier Radio 
Waveform (SRW) which uses a non-IP addressing scheme over the RF system. 2 
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During the PAS Interface Testing of August 2013, initial NTP testing showed NTP worked, but not 
without issues. NTP operates under the assumption that higher tiered clock data is available to the lower- 
tiered clocks for long periods of time. 23 Over time, the NTP slave devices slowly begin to “trust” the more 
stable master clocks based on their observed performance, and the slave devices will eventually begin to 
more aggressively synchronize with these clocks. Since the suit electronics are only powered up for several 
hours at a time, this process is too long and involved for this application. The behavior of NTP can 
be and was modified to suit the needs of PAS, but most of these modifications simply disabled a lot of the 
advanced functionality of NTP. Periodic, forced synchronizations with the Communication timestamp might 
be sufficient to maintain clock synchronization between the PAS assemblies over the duration of an EVA, 
and the same is true between Communication and its higher-tier clock (HOME, Mission Control, etc.). 

If the SRW or some derivation were to be used for the radio system - at least the critical communica- 
tions portion - the SRW has multiple time-synchronization mechanisms that could be used to synchronize 
the AEMUs with the Communication timestamp used to maintain clock synchronization between the PAS 
assemblies. 

Navigation 

Navigation research related to AEMU development and EVA’s is mainly concerned with terrestrial nav- 
igation for both safety and to be able to mark locations during science EVAs (i.e. where and when was a 
particular sample taken). 

In preparation for the Constellation Program, NASA was interested in finding new methods of surface 
navigation to allow astronauts to navigate on the lunar surface. The interest is still there, but in more 
general terms than terrestrial navigation. 

In support of the Vision for Space Exploration, the NASA GRC developed the Lunar Extra- Vehicular 
Activity Crewmember Location Determination System and performed testing at the Desert Research and 
Technology Studies event in 2009. A significant amount of sensor data was recorded during nine tests 
performed with six test subjects. 24 

Technology related to terrestrial navigation is likely to move ahead within the commercial and military 
arena at a far greater pace and with far greater investment than NASA can provide. Thus, no new research 
is currently planned as no terrestrial EVAs are expected any time soon. 

D. Informatics 

The Informatics assembly is a computerized system aiding crewmembers in their exploration missions. The 
operational goal is to increase EVA crewmember productivity and effectiveness and decrease the amount of 
mission support provided by ground-based controllers. 

Functionally, the Informatics assembly provides information to be displayed for real-time navigation 
and tracking, along with productivity and work enhancement aids such as task procedures, checklists, and 
schedule coordination. It also displays situational awareness information, such as physiological data and 
consumable usage. 

The Informatics subsystem performs only non-critical functions and therefore is assigned a Criticality 3 
designation. Associated software is Class C. Failures within these will not result in a loss of life nor loss 
of mission. If this subsystem is down, the crew could continue to perform an EVA, but might not be as 
productive. 

1. Implementation 

For the tabletop breadboard, Informatics was implemented using a Beaglebone Black development board 
(http : //beagleboard. org/Products/BeagleBone+Black) . Some of the salient characteristics are: 

• TI OMAP processor 

• Linux Operating System 

• 1 GHz ARM 7 architecture 

• 512 MB RAM 

• Power VR 3D GPU 

• File system on micro-SD card (16 GB currently) 
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E. Storage 

A separate storage unit is not part of the Power, Avionic and Software 1.0 implementation. In PAS 1.0 all 
subsystems are responsible for providing their own storage. 

The Storage Assembly is a non-volatile mass storage for the entire PAS Subsystem. This assembly 
is considered a secondary storage unit and not directly accessible by each of the assembly’s processors; 
rather, each assembly will access it through their input/output channels via the subsystem bus. The Storage 
Assembly is considered to be all of the associated components that retain the digital data for use by the user 
and data stored by the PAS Subsystem for archiving. 

The storage subsystem is assigned a Criticality 3 designation and associated software is assumed to be 
Class C. Failures within these will not result in a loss of life nor loss of mission. If these systems were down, 
the crew could continue to perform an EVA, but might not be as productive. 

F. Video 

The Video Camera is a self-contained unit. It is interfaced independently and directly to the PAS Subsystem 
data bus; therefore, the video data travels on the same bus as other the other PAS data. This interface 
requires physical, link, network, and transport layer Open System Interconnection (OSI) bus functions. 
Video imaging is the suit’s highest data rate source, dwarfing most other suit data by a factor of 10 or more. 
The lens and sensor for the camera is expected to be located on either side of helmet with fixed field of view 
(FOV). Storage for video is expected to take place in Informatics for PAS 1.0 implementation. The Video 
Camera assembly is assumed to be a low criticality device. 

For the PAS Interface Testing during August of 2013, 20 a commercial-off-the-shelf high definition webcam, 
a SANYO® VCC-HD4600, was used simply to load the GigE bus as much as possible. No storage was 
performed. 

G. Monitoring, Test and Validation 

The MTV system primarily monitors the GigE subsystem bus and the wireless links and creates the neces- 
sary signals to exercises various subsystems (e.g., subsystem configurations, multiple VOIP streams). The 
Validation system displays telemetry in a manner that can be used for debugging bus activity as well as 
validate test commands. The Test portion of MTV is a packet generation tool to exercise various subsystem 
commands over the GigE bus. This is particularly useful for debugging one subsystem independently of 
another. 

For the PAS Interface Testing during August of 20 13, 20 the MTV was actually distributed over a number 
of systems. Informatics implemented a number of event messages that would normally be sourced by other 
subsystems in order to test the Informatics display capabilities. Likewise Audio implemented four input 
streams using four netbooks. A separate netbook was used to monitor the Ethernet bus using Wireshark® 
software and for capturing and playing video from the HD Camera. 

VIII. Intersystem Communications 


A. Design Philosophy 

Subsystem communications is performed via a Publish/Subscribe mechanism using the ZeroMQ software 
library. ZeroMQ also supports a Request/Response mechanism, but it was avoided because it requires 
maintaining additional software state and is more prone to race conditions, deadlock and other software 
complications. 

Note, throughout this document that the term “command” is intentionally avoided as “command” often 
has a connotation of request /response communication. 

We are using only ZeroMQ publish and subscribe sockets to move data packets between computers. The 
format of the data packets is defined using GPB in a common AEMU. proto file. Each message type has 
specific parameters associated with it. 
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B. Messages 


Each message has the structure shown in Figure 3. The required fields are shown in Table 1. These required 
fields may be followed by various parameters, some which must be present and some which are optional 
depending on the particular message. 


Table 1. Required Fields 


sender 

integer 

A number identifying the sender (1 for CWCS , 4 for Informatics, etc) 

timestamp 

double 

The time the message was sent (Unix time plus fractional part, seconds 
since January 1, 1970) 

type 

integer 

A number identifying the message type (which determines the additional 
fields in the message) 


The following are the message types taken from the AEMU. proto file - see reference 7 . They are split 
into Implemented Messages and Future Work / Future Considerations. The latter are place holders for 
functionality the we currently believe requires a message for some controlling source and are thus, generally 
EVENT type messages. Often, the need for these messages depends on which subsystem owns and controls 
buttons and switches. If particular control buttons or switches belong to the subsystem, there is no need for 
configuration messages to be transmitted between subsystems. However telemetry “Status” messages could 
still be used by Informatics or CWCS to validate switch settings. 

1. Implemented Messages 

The following messages were implemented and tested during the Intersystem Communication Testing during 
August of 2013: 20 

General Messages 

EVENT.TEXTJVIESSAGE 
EVENT JBUDDYJNFO 

CWCS Messages 

TELEMETRY. CWCSJ3TATUS 
TFT EMFTRY CWCS CONST TM ARTE PQ2 
TETEMFTRY CWCS CONST TMABTE SQ2 
TFT EMFTRY CWCS CONSTTMARTE HATT 
TETEMFTRY CWCS CONST TMABTE H2Q 
TEITMETRY.CWCSEAimONWARNING 
TETEMFTRY CWCS PHYSTO 
TETEMFTRY CWCS RASTCS 
TETEMFTRY CWCS TWO TINE DTSPT.AY 

COMM Messages 

TETEMETRY_COMM_STATUS 

Audio Messages 

TELEMETRY AUDIO-STATUS 

TFT EMFTRY ATTPTO STATUS OUTBOUND 

TETEMFTRY ATTPTO STATTTS TNHOTTNP 

EVENTELAY AUDIO 

EVENT AUDIO _SET_VOLUME_CHANNELS 

EVENTAUDIO_SET_VOLUME_TONES 

INFO Messages 

TELEMETRY TNFO STATTTS 
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An example, the details of and implementation code for the message EVENT_BUDDY_INFO is provided 

? 

m • 


2. Future Work / Desired Functionality 

The following messages are for are functionality we believe need to exist, but are currently unimplemented: 

COMM Messages 

EVENT_COMM_CONFIGJREBOOT (Deprecated) 

EVENT_COMM_CONFIG_UPDATE 

EVENT_COMM_CONFIG_CRITICALJRADIO 

EVENT_COMM_CONFIGTnGHJlATEJlADIO 

EVENT_COMM_CONFIG_CALL_GROUPJtADIO 

System and subsystem reboot message were considered. However, if a subsystem goes down, it probably 
cannot receive a reboot message. Rather, one would probably have to reboot via some type of power cycle. 
Thus, the notion of rebooting subsystems appears to be valid, but how to actually accomplish this has yet 
to be resolved. 

The Communication system configuration consists of routing information and radio configuration. The 
radio configuration could include data rates, modulation formats, media access types (e.g. time-division- 
multiplexed or frequency-division- multiplexed) and perhaps a variety of waveforms. Who controls these 
waveforms and configurations is TBD. The initial thought is that this is a Mission Operations Center (MOC) 
function. 

Call group configuration may be controlled by the MOC. Or, the MOC may configure the possible call 
groups with the crewmember controlling which call group they are participating in via a switch on the radio 
or via voice-commanding. 


IX. Summary 

The current EMU suits (space suits) are still using technology from the 1970’s and 1980’s, particularly 
regarding the communications system. In order to infuse new technologies into the EMUs and prepare for 
future NASA missions, NASA is currently developing an Advanced Extravehicular Mobility Unit (AEMU). 
A key part of this development is the spacesuit Primary Life Support Subsystem (PLSS) technology unit for 
long-duration microgravity or planetary missions and vacuum or low-pressure environments. NASA GRC’s 
role is to develop a prototype suit avionics subsystem and to research new technologies for the AEMU. The 
first iteration of the prototype suit avionics, Power, Avionics and Software (PAS) 1.0, has been completed. 
Some of the noteworthy items related to the PAS 1.0 Communication Architecture include the following: 


• A distributed architecture was used for two main reasons: to allow separation of software and hardware 
criticality and to allow subsystems to develop independent of each other. This was particularly useful 
for separation of research and technology development in the Audio and Communication subsystems 
while allowing the CWCS to be implemented with a nearer-term path to flight goal. 

• Use of a gigabit Ethernet bus enabled use of common off-the-shelf drivers and hardware greatly sim- 
plified subsystem communication integration. 

• Use of Google Protocol Buffers greatly simplified message structures while allowing flexibility and 
expandability in the various messages. 

• Use of ZeroMQ simplified communication between subsystems as we could concentrate on the message 
structure rather than the messaging implementation. Furthermore, ZeroMQ allows us to move from 
UDP transport to IPC or in-process shared memory without changing the message structure. 
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